It looks to me that it always use start of 1st leg. Even though other legs have their own start times.
Before race this is correct output.
However, if we export XML during the race, we will lose the actual start times of the other legs.

Do we know of any system outside of QE that need start times of all legs (as export from QE) ?

Start time of next leg is finish one of prev leg, there should be NULL for each leg except of the first one, unless previous leg is finished. There is IMO nothing like implicit start time for legs no > 0.

StartTime element has to be present and can't be null. It makes sense to have the same start time for all legs as initial state.

It looks to me that it always use start of 1st leg. Even though other legs have their own start times. Before race this is correct output. However, if we export XML during the race, we will lose the actual start times of the other legs.

Do we know of any system outside of QE that need start times of all legs (as export from QE) ?

It could be adjusted to respect calculated start time for the next legs (2,3,..).

The idea came from visualization app in OFeed few years ago. The initial state wasn't working because next legs had earlier start time than the first leg.

What if we use simply 0 if start element cannot be omitted in case when it doesn't make sense?

IOF v3 standart definition say that minOccurs="0". So it can be empty.

To export relays (start list, QE2) to IOF Eventor for WOC2021 and WC2023, the start time of the first leg was used for each leg. And in export for JWOC2024 from Kramer was for each leg used start time of first leg.

I tested import of WC2023 SprintRelay without start times for other legs in Test Eventor and Eventor accepted it. OResult accepted both variants.

I think it's better if empty value is not replaced with value from the first leg.

But on the other hand, I haven't any problem with start time of 1st leg for other legs.

Good point, thanks for check — we should keep things consistent in QuickEvent. For races with a free start (start interval 0), we also export the same start time (startTime) for all competitors, so if we decide to omit the StartTime element for relays, we should do the same for competitors in free-start races.

At O-Replay, when we parse relay files, we expect the StartTime to be missing for all legs except the first one until the actual start time is known. This behaviour could be changed, of course, but for now we assume no placeholder is sent.

This approach also adds some flexibility. All three legs can run at the same time, and their times will be accumulated into their teams live time. I’m not sure whether you have such scenarios where multiple legs run concurrently in Czech Republic. In Spain, this can happen when one leg is too slow and the next leg starts with a second mass start.

I don't want to change your mind, but to show our vision on the problem. By the way, you can check how we display relays here (all features are not finished though).

@fvacek thanks for assigning 🙂 I'll try to remove the startTime element for both relays (except the first leg) and categories with free start (start interval 0).

How can I distinguish between mass start and free start (punching start unit)?

How can I distinguish between mass start and free start (punching start unit)?

I'm afraid, I do not understand question. May be this topic is brand new for me.

Mass start - individual race, all competitors start at the same time

Free start - classes for the beginners (e.g. DH10F) and families (e.g. HDR) that start in dedicated time period "without" startlist, they punch the start unit at start line.

In both cases all competitors in the class have the same start time.

For mass start event discipline (#1112) can be used i guess.